@turing85 I'd like to do a new release of 2.x after merge this PR. WDYT?

@turing85 I'd like to do a new release of 2.x after merge this PR. WDYT?

@zhfend ythis is fine by me, yes. We should, however, create a ticket, so we do not forget to upstream the fix when the fix is done in 3.0.0.

Yeah, I raise a ticket for remvoing this dependency when Quarkus 3.0.0 has a new release.

@zhfeng quarkus-artemis 2.0.5 has been released.

@turing85 Well, this new release is not backwards compatible because we change to use ConnectionFactoryWrapperBuildItem in quarkus-jms-spi-deployment. I wonder if we can bump to 2.1.0 at lease?

@zhfeng hmm... yes we can. But... I cannot undo what I have done, i.e. 2.0.5 will stay broken. Maybe:

• rollback the changes,
• do a 2.0.6 release,
• roll back the rollback, and
• do a 2.1.0 release?

@zhfeng In the mean time, I updated the release notes for version 2.0.5 and added the breaking change.

Thanks @turing85 and IMO, it could be good to just release 2.1.0 and no 2.0.x anymore. @gastaldi we met this backwards compatible issue and just wonder what is the best way from the maintenance perspective?

I have a similar issue with quarkus-pooled-jms and include un-compatible commit in a new release 1.0.9 😢

@zhfeng okay, building 2.1.0 right now 👍

@zhfeng quarkus-artemis version 2.1.0 has been released.

Thanks @turing85 and IMO, it could be good to just release 2.1.0 and no 2.0.x anymore. @gastaldi we met this backwards compatible issue and just wonder what is the best way from the maintenance perspective?

You could have a 2.0.x branch and release independently if you want,but I don't know if it's worth the effort

Let's wait until someone asks for it